Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bgpd: fix consider in NHT BGP update with same prefix/nexthop #17428

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pguibert6WIND
Copy link
Member

All BGP configuration do not consider any BGP updates which have the same prefix and nexthop. Example:

p2# show bgp ipv4
BGP table version is 2, local router ID is 198.51.100.3, vrf id 0
Default local pref 100, local AS 65500
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

i198.51.100.5/32 198.51.100.5 0 100 0 i

The consequence is that this BGP update is not considered as reachable, and is not redistributed. This is an issue on a Route Reflector case.

The previous fix prevented from handling this kind of update; testing the reachability of such nexthop would lead in a loop, from routing perspective. In reality, that BGP update is frequently used in networks, today.

Fix this by considering the BGP update, only if there is an existing bnc entry.

All BGP configuration do not consider any BGP updates which have
the same prefix and nexthop. Example:

> p2# show bgp ipv4
> BGP table version is 2, local router ID is 198.51.100.3, vrf id 0
> Default local pref 100, local AS 65500
> Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
>                i internal, r RIB-failure, S Stale, R Removed
> Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
> Origin codes:  i - IGP, e - EGP, ? - incomplete
> RPKI validation codes: V valid, I invalid, N Not found
>
>     Network          Next Hop            Metric LocPrf Weight Path
>    i198.51.100.5/32  198.51.100.5             0    100      0 i

The consequence is that this BGP update is not considered as reachable,
and is not redistributed. This is an issue on a Route Reflector case.

The previous fix prevented from handling this kind of update; testing
the reachability of such nexthop would lead in a loop, from routing
perspective. In reality, that BGP update is frequently used in networks,
today.

Fix this by considering the BGP update, only if there is an existing
bnc entry.

Signed-off-by: Philippe Guibert <[email protected]>
Copy link
Member

@ton31337 ton31337 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide a topotest covering this RR case also.

@donaldsharp
Copy link
Member

Can you give me examples of when a prefix and the same nexthop are allowed and not allowed? I'm a bit confused about what this is now.

@ton31337
Copy link
Member

This is something like: 198.51.100.5 (iBGP neighbor), which is usually accessible via IGP(not BGP?), so there might be a case.

@riw777 riw777 self-requested a review November 26, 2024 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants